15:07 <Akien> Next: #21014
15:07 <IssueBot> #21014: Add String support for GDScript Enums | https://git.io/fNNKC
15:07 <bojidar_bg> NB: I'm biased towards close here
15:07 <Akien> I'm not sure we should have this feature in the first place either.
15:08 <bojidar_bg> it might make enum-typed parameters harder to implement
15:09 <vnen> I don't think it's needed. I see it as a solution to a lack in the language somewhere else
15:10 <bojidar_bg> Also, it will break with export(Enum)
15:10 <vnen> for instance, it should be easier to get the name from an enum value
15:10 <bojidar_bg> (ah, nevermind my last message)
15:11 <Akien> Yeah, being able to get the enum identifier as a string would be quite nice.
15:11 <Akien> It seems like this PR only means to address the inconsistency between having enum String hints in exports, which map to int values
15:12 <vnen> I do: `MY_ENUM.keys()[enum_value]`, but that doesn't work with custom assignments
15:13 <bojidar_bg> Maybe something like Dictionary.reverse() which builds a dictionary by swapping the key and value in each entry?
15:14 <bojidar_bg> or, something like what I've done in the asset library: enums which have both the string key -> integer value mapping and the integer value -> string key; this would allow for doing `MY_ENUM[enum_value]` directly
15:15 <Akien> Note that it would also be useful to retrieve string names from built-in enums and constants, like converting Error codes to something user readable.
15:16 <bojidar_bg> Well, another option would be to have a Variant::Enum type which contains an integer and enum name/dictionary/?
15:17 <bojidar_bg> ... which would basically be a Symbol/StringName-like type with a custom lookup table..
15:18 <vnen> I guess we agree to close the PR, we can discuss a solution later
15:18 <bojidar_bg> we should probably close the issue as well, and find another one for the discussion